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AMENDMENTS TO THE SPECIFICATION: 

Please amend the paragraphs beginning at page 1, lines 6-12, as follows: 

TECHNICAL FIELD O F THE I NV ENTION 

The technical filed of the present iaveatiefl- disclosure relates to 
arrangements and a method in a third generation mobile telecommunication 
system and evolved variants thereof. In particular, the invention relates to 
arrangements and a method for handling macro diversity in a UMTS Radio 
Access Network (UTRAN). 

Please amend the paragraphs beginning at page 5, line 8 through page 
6, line 7, as follows: 

The consumed transmission resources are reduced according to a non- 
limiting aspect the present invention by distributing the macro diversity 
functionality to the Node Bs. A problem is then how to select which of the 
connected Node Bs that should be selected to perform the combining/ splitting 
function, also referred to as a Diversity Handover (DHO) function. These 
selected nodes are referred to as DHO nodes. The DHO nodes--h ave to b eare 
selected out of those Node Bs that are able to perform the DHO functionality, 
i.e. out of those Node Bs that have been adapted with DHO functionality-and 
othe r functieas- of the present invention . These nodes are referred to as DHO 
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enabled nodes or macro diversity enabled nodes. One non-limiting example 



disclosure , however other methods may also be used. When the DHO nodes are 
selected e.g. in accordance with the disclosed method, a method and 
arrangements for executing the macro diversity is required. 

T he object of the pre s eat in v ention is-th-bts- to provide - a - method -afid 



28 an 4-45-a nd the method of claim 1 . 

Thc -HK;>«4r+)r>oort.an1 advantage One of several significant advantages 
achieved by the present invention is transmission savings in the UTRAN 
transport network, which translate into significant cost savings for the 
operator. The transmission savings are realised through optimised location for 
the DHO functionality. Thereby the redundant data transport is eliminated in 
the parts of the path, where data pertaining to different macro diversity legs of 
the same DCH would otherwise be transported in parallel along the same 
route. 

Another advantage of the present invention is that ifc-fae ilitates th at- the 
RNCs may be located in more central locations of the network (i.e. with less 
geographical distribution). The main purpose of the current common 
geographical distribution of RNCs is to limit the transmission costs for the 
parallel macro diversity legs. When this parallel data transport is eliminated, it 



method for selecting the DHO nodes is disclosed in- 




this 



arraag&iaeftt s for executing the - 



-dwersityMfo nction , 
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becomes more beneficial for an operator to centralise the RNCs, e.g. by co- 
locating them with MSCs or MGWs. Co-locating several nodes on the same site 
results in simplified operation and maintenance, which also means reduced 
costs for the operator. 

Please amend the paragraphs beginning at page 6, lines 22-24, as 
follows: 

FIG. 4 illustrates the-potential transmission savings in an illustrative 
non-limitin g example with cascaded Node Bs ;hx ording to the present 
invention. 

FIG. 5 illustrates a non-limiting example scenario with a mobile terminal 
using five macro diversity legs according to the present invention . 

Please amend the paragraphs beginning at page 6, line 27 through page 
7, line 1, as follows: 

FIG. 7 shows the-a_branching node tree corresponding to the route tree 
in FIG. 6. 

FIG. 8 shows tfee-aDHO node tree resulting from the-selection of DHO 
nodes corresponding to the branching nodes of the example depicted in FIG. 5. 
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Please amend the paragraph beginning at page 7, line 5, as follows: 

FIG. 10 shows the- a non-limiting example of a modified DHO node tree 



after the first step of the delay reduction method number 5-are eording t o a n 

em bodiment of the inventio n:. 

Please amend the paragraph beginning at page 7, line 9, as follows: 

FIG. 12 shows the modified DHO node tree after the second step of the 
delay reduction method number 5 according to an embo di ment of the 
invention. 

Please amend the paragraph beginning at page 7, line 13, as follows: 

FIG. 14 shows the modified DHO node tree after the third step of the 
delay reduction method number 5 acc o rding to an embodiment of the 
invention -. 

Please amend the paragraph beginning at page 7, line 19, as follows: 



FIG. 17 is a flowchart of the- a non-limiting example method accordin ^te 



fe e ... p Fe .. S@B 4: ..... [ H . Ve . H .. ^ eK- 

Please amend the paragraphs beginning at page 8, lines 1-20, as follows: 

In the further description of the present invention coordinated DCHs are 
not specifically treated. In the aspects that are significant, to the pre s e - n -t 
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invention a set of coordinated DCHs is treated in the same way as a single 
separate DCH. The DCHs of a set of coordinated DCHs use a common 
transport bearer and in an IP UTRAN the frames (of a set of coordinated DCHs) 
with the same CFN are included in the same User Datagram Protocol (UDP) 
packet. The special combining procedure for coordinated DCHs has been 
described above. Thus, omitting coordinated DCHs serves to simplify the 
description e^the^fesent in ve n&en-and makes the text more readable. To 
generalize the description of the present invention so as to comprise 
coordinated DCHs would be conceptually trivial for a person of ordinary skills 
in the art, although it would significantly complicate the text. 



implemented in a third generation mobile telecommunications system, e.g. in a 
UMTS, and in particular in the Radio Access Network (RAN), e.g. a UMTS 
Terrestrial Radio Access Network, UTRAN. Such a system is illustrated in FIG. 
1 and described above in conjunction with FIG. 1. 

In order to reduce the required transmission resources, fee- prese nt 



from the RNC to other nodes for macro diversity configurations for which this is 
beneficial from a transmission point of view. These other nodes are typically 
Node Bs, but may also be other types of nodes, e.g. specialized Diversity 
Handover nodes. The potential transmission savings when the macro diversity 
is distributed to Node Bs are illustrated in FIG. 4. When a macro diversity 




- One or more non-limiting aspects may be 



n=epeses- it is proposed to distribute the macro diversity functionality 



-6- 



1-173718 



AMENDMENT 

U.S. Serial No. 10/583,894 



Atty. Docket No.: 2380-1325 
Art Unit: 2617 



configuration, also referred to as a Diversity Handover (DHO) node tree (the 
term "DHO node tree" is further explained later) is established, or changed, it is 



i.e. the Node Bs that should perform the actual combining and splitting, before 
the macro diversity function is executed. The DHO nodes h^e-te- should be 
selected out of the available nodes that comprise DHO functionality, i.e. out of 
the DHO enabled nodes (typically DHO enabled Node Bs and RNCS). In the 
non-limiting examples below, the Node Bs and the RNC are used as DHO 
nodes, but it should be noted that other nodes such as specialized DHO nodes 
or logically or geographically distributed RNCs or future types of nodes 
implementing parts of the RNC functionality also may be used as DHO nodes. 

Please amend the paragraph beginning at page 9, line 20, as follows: 

Below is an An example illustrative non-limiting of a method for selecting 
DHO nodes disclosed is described below . It should however be noted that other 
methods for this selection also may be used4fi-eenjur^^an- with the p resent 
inwnti-en. 

Please amend the paragraphs beginning at page 10, line 5 through page 
11, line 20, as follows: 

The- To enable selection of the DHO node(s}^^uires~feat the RNC 
eempt4ses-of4&- should have or be adapted to retrieve information about the 




- preferred to select the Node Bs that should be the DHO nodes, 
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topology of the UTRAN, both the UTRAN transport network and the Node Bs 
and RNCs. Different levels of richness of this information are conceivable. The 
choice of this level is a trade-off between the value it provides for the DHO node 
selection mechanism and the complexity it implies for the selection mechanism 
as well as the topology information retrieval mechanism. A certain level of 
flexibility of the richness of the topology information will be allowed in the 
further description of the DHO node selection. 

However, the-a non-limiting; example topology information with a basic 
level of richness comprise s can include : 

-A hop-by-hop route from the RNC to each Node B that is controlled by 
the RNC and possibly some Node Bs that are controlled by neighboring RNCs, 
wherein each router is represented by the IP address associated with the 
interface that is used to forward packets in the direction of the RNC. The Node 
B is represented by one of its IP addresses, e.g. the one used for NBAP (Node B 
Application Part) signaling (or the primary IP address used for NBAP signaling 
in case multiple IP addresses are used for NBAP signaling). If a neighboring 
RNC is included in a hop-by-hop route, it is also represented by one of its IP 
addresses, e.g. the one used for RNSAP (Radio Network Subsystem Application 
Part) signaling (or the primary IP address used for RNSAP signaling in case 
multiple IP addresses are used for RNSAP signaling). 
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-A delay metric for each hop in a route. If no explicit delay metric is 
available, an approximation can be derived from the generic cost metric, which 
is described below, or all hops can be given the same delay metric. 

-A generic cost metric for each hop in a route. If no such generic cost 
metric is explicitly available, a reasonable approximation can be derived from 
the delay metric or a fixed default cost metric can be used for all hops. 
Preferably, the RNC is adapted to use the topology information to maintain 
data representations of the hop-by-hop routes with associated metrics to all the 
Node Bs in the Radio Network Subsystem (RNS) (and possibly to some Node Bs 
controlled by neighboring RNCs, i.e. Node Bs in neighboring RNSs), The RNS 
comprises the RNC and the Node Bs that are controlled by the RNC. Then the 
routes are readily available when needed for a DHO node selection process. 
However, retrieving topology information and creating the hop-by-hop routes in 
real-time when needed is also a possibility if the RNC maintains a generic 
topology database. For instance if the Transport Network Layer (TNL) in the 
RNC maintains a link state routing topology database, it is conceivable that 
this database is consulted (e.g. by letting the Radio Network Layer (RNL) of the 
RNC interrogate the TNL of the RNC) in order to create the required hop-by-hop 
route representations in real-time. From a performance perspective it is 
preferable that the hop-by-hop routes are readily available when they are 
needed. 
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In addition to the required topology information the RNC gaast- should be 
manually or automatically configured with knowledge about the relevant Node 
Bs that are able to comprise DHO functionality, also referred to as DHO 
enabled nodes. The DHO enabled nodes are -include at least c onstitu ted-by-the 
DHO enabled nodes controlled by the RNC, but in inter-RNS macro diversity 
configurations they may also include other RNCs and Node Bs controlled by 
other RNCs. It is also possible that the DHO enabled nodes may include other, 
yet non-existing, types of Radio Network Layer (RNL) nodes, e.g. specialized 
DHO nodes. The RNC i^^equired^o -should know at least one IP address of 
each DHO enabled node, preferably the IP address used for NBAP signaling (or 
RNSAP signaling in the case of an RNC). This IP address is required te -should 
be the same IP address as is used to represent the node in a hop-by-hop route. 
The RNC may be adapted to use the list of DHO enabled nodes to include an 
indication of whether the node is DHO enabled or not for each node in the hop- 
by-hop routes. 

Please amend the paragraph beginning at page 12, line 13, as follows: 

In the case when the UTRAN transport network is ATM based, the 
topology database is based on ATM addresses instead of IP addresses. 
Otherwise the general properties of the topology database are similar to the 
properties of the database in the IP based UTRAN. Each hop in a hop-by-hop 
route is represented by an ATM address. For each hop there is an explicitly 
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defined or implicitly derived generic cost metric and an explicitly defined or 
implicitly derived delay metric. In the ATM based UTRAN, the topology 
database has-te- can be created through manual or semi-automatic 
management operations. The RNC uses the topology database in the same way 
in the ATM based UTRAN as in the IP based UTRAN. 



Please amend the paragraphs beginning at page 12, line 25 through 
page 14, line 7, as follows: 

It should be noted that, although the procedures of the DHO node 
selection algorithm are described below using the terminology of an IP UTRAN, 
they are equally applicable in an ATM UTRAN. In an ATM UTRAN the 
algorithms and procedures are the same similar , but where the routers are 
replaced by AAL2 switches and the IP addresses are replaced by ATM 
addresses. 

The mechanism that the RNC is adapted to use in order to select the 
DHO node(s), i.e. the node(s) where the splitting and combining will be 
performed, is(are) substantially the same whether optimized NBAP and RNSAP 
signaling is used or not. One object of the DHO node selection mechanism is to 
select the DHO nodes in a way that minimizes one or more accumulated metric 
for the ail the macro diversity legs. Such an accumulated metric may be a 
generic cost metric. This cost metric may be put together with tfee-a^condition 
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that for none of the resulting data paths is the resulting path delay allowed to 
exceed a maximum delay value defined for the UTRAN. 

In the typical scenario, a DCH is first established with a single leg, i.e. 
without macro diversity. When a second macro diversity leg is added, the RNC 
selects a DHO node for these two legs and redirects the existing data flow if 
necessary (i.e. unless the selected DHO node is the Node B of the first leg or the 
RNC itself. When a third leg is added, the RNC is geeftrifed- likely to rerun the 
DHO node selection process from scratch, since the addition of the third leg 
may affect the selection of the first DHO node. T-he- Alternatively, the RNC also 
has the choice to let the third leg go all the way to the RNC (without trying to 
find a better DHO node) in order to not to affect the previous DHO node choice 
and to avoid the signaling involved in redirecting the existing flows, The same 
(i.e. rerunning the DHO node selection process from scratch or terminating the 
new leg in the RNC) applies to subsequently added macro diversity legs. 

T-he- A non-limiting example DHO node selection mechanism relies on the 
above described topology information involving both transport networks nodes 
(routers) and radio network nodes (Node Bs and one or possibly more RNCs). It 
also utilizes the list of DHO enabled nodes connected to the RNC (and possible 
some DHO enabled nodes in neighboring RNSsj^ 

The RNC selects a first set of preliminary DHO nodes in a way that 
minimizes the total accumulated generic cost metrics for the entire macro 
diversity tree. It then checks whether the maximum allowed path delay is 
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exceeded for any of the macro diversity legs according to one nondimiting 
embodiment. If the path delay is acceptable, the set of preliminary DHO nodes 
is- can be kept. Otherwise the set of preliminary DHO nodes is- can be modified 
by the RNC in a way that reduces the path delays until the path delays of all 
macro diversity legs are acceptable. 

Selection of the First Set of Preliminary DHO Nodes 

In short the RNC starts the DHO node selection process by forming a tree 
of the routes (retrieved from the topology database) to the involved Node Bs. It 
then identifies the branching nodes in the tree and their relative 
interconnections. Identifying the relative interconnections of the branching 
nodes in essence meane- implies that the RNC creates a simplified schematic 
tree e onoioting of that includes only branching nodes, Node Bs and the RNC 
(i.e. intermediate routers are omitted). The simplified schematic tree is 
illustrated in FIG. 7. For each branching node there is a corresponding 
potential DHO node and the RNC is arranged to proceed to select these DHO 
nodes. A detailed description of the complete process follows below. 

Please amend the paragraph beginning at page 20, line 10, as follows: 

The algorithm used for selecting a DHO node corresponding to a certain 
branching node is simple. Starting from the branching node the RNC is able to 
accumulate the generic cost metric in each direction (i.e. in the direction of 
each branch in the original route tree including the uplink) from the branching 
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node until a DHO enabled node (or the end of the path) is found. (If asymmetric 
generic cost metrics are used, the generic cost metrics has to should be the 
accumulated roundtrip from the branching node to the found DHO enable node 
and back. If symmetric cost metrics are used it suffices to accumulate the 
generic cost metrics in one direction.) The RNC does this by using the original 
route tree—not the simplified one. The DHO enabled node that was found with 
the smallest accumulated generic cost metric is selected as the DHO node 
corresponding to the concerned branching node. If the branching node is itself 
a DHO enabled node, it will of course be the selected DHO node, since it is 
obviously the best choice and the accumulated generic cost metric will be zero. 

Please amend the paragraph beginning at page 21, line 7, as follows: 

Returning now to the DHO node selection example based on the example 
scenario in FIG. 5, the DHO nodes corresponding to the identified branching 
nodes will be selected as follows. Since symmetric generic cost metrics are used 
in this example, the cost metric is accumulated in only a single direction 
between a branching node and a potential DHO node. The DHO node 
corresponding to branching node R7 is NB4, for which the accumulated generic 
cost metrics from R7 is 4. All the other DHO enabled nodes in the route tree 
have greater accumulated generic cost metrics from this branching node. 
Similarly, the selected DHO node corresponding to the branching node R5 is 
NB3, for which the accumulated generic cost metrics from R5 is 4. The selected 



. 14. 



AMENDMENT 

U.S. Serial No. 10/583,894 



Atty. Docket No. : 2380-1 325 
Art Unit: 2617 



DHO node corresponding to the branching node R4 is NB3 again, for which the 
accumulated generic cost metrics from R5 is 7. The selected DHO node 
corresponding to the branching node R2 is NB1, for which the accumulated 
generic cost metrics from R24s- 4 is 1 . 

Please amend the paragraphs beginning at page 36, lines 10-12, as 
follows: 

Realization of a DHO Node Tree 

When the DHO nodes, also referred to as macro diversity nodes, are 
selected e.g. according to the above described method, the RNC instructs the 
DHO nodes and other affected nodes so that the intended macro diversity is 
established-a ccording to the present -kt ventioH . DHO nodes receive instructions 
from the RNC by means of NBAP or RNSAP ( RNSAP io only used in the inter- 
RNS case) and perform the following in accordance with said instructions 
according to one or more non-limiting embodiments.H9#4ft- e prcsen t4rrvenfeie-m 

Please amend the paragraphs beginning at page 37, lines 1-15, as 

follows: 

When unmodified NBAP and RNSAP is used the DHO nodes may be 
adapted to split the downlink flow and to forward the resulting flows according 
to implicit information in the uplink data flow received from hierarchically 
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lower nodes. This implicit information 



- can include source IP 



addresses and UDP ports retrieved from the IP header and UDP header of 
received uplink packets. 
For the uplink: 

The DHO nodes are adapted to combine the uplink flows to a single 
uplink flow that is forwarded according to the instructions received from the 
RNC using a previously established transport bearer. The instructions may 
comprise IP addresses in an IP-based UTRAN or ATM addresses and SUGR 
parameters in an ATM based UTRAN. When unmodified NBAP and RNSAP are 
used the DHO nodes are -can be adapted to identify the uplink flows to be 
combined through information retrieved from uplink packets received from 
hierarchically lower nodes. 

The Node Bs with DHO functionality preferably use an adaptive timing 
scheme to optimise the trade-off between delay and frame loss in the uplink 
combining. T4ie--toirig--s€fa^^ n e t within the sc o p e of the -presen-fe 

invc-ntio-nr 

Please amend the paragraphs beginning at page 37, line 22 through 
page 38, line 29, as follows: 

It should be understood that the method using instructions or other 
means to establish the macro diversity in accordance with the (logical) DHO 
node tree is independent of the method that is disclosed to obtain or create the 
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(logical) DHO node tree. Any other method to create the (logical) DHO node tree 
(i.e. to select the DHO nodes) can be used- in - eomb i nation with th e pr e sent 
invention. 

If a transport network control plane protocol is used, the selected Node 
Bs with DHO functionality may u se this control plane protocol to establish the 
inter-Node B transport bearers according to the instructions from the RNC. 
Examples of such transport network control plane protocols ar^include, 
among others. O.2630 (for AAL2 connections) in an ATM based UTRAN and the 
control plane protocol being developed by the NSIS (Next Step In Signaling) 
workgroup in the IETF (Internet Engineering Task Force) in an IP based 
UTRAN. 

To establish a hierarchical macro diversity structure the selected DHO 
nodes necd-to-should be instructed so that they know where to send split 
downlink flows and what uplink flows to combine. These DHO node 
instructions afe- can be based on the DHO node tree that is the outcome of the 
DHO node selection process. Every time the DHO node tree changes (due to 
addition or removal of macro diversity legs) some or all the affected nodes (both 

DHO nodes and non-DHO Node Bs) need new instructions. Instructions ar e 

afee- Changed instm ctions may also be needed when DCHs are added or 
removed from all macro diversity legs. DHO nodes may also accordin g-te 
embed4me nts of the present invention -need QoS instructions when DCHs are 
modified in a way that the QoS of their transport bearers have to be changed. 
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The affected nodes may range from a single to all Node Bs in the DHO node 
tree. No signaling is required when only the S-RNC is affected. 
Realizing a DHO Node Tree with Modified Protocols 

In order to direct the DCH data flows in accordance with the DHO node 
tree the RNC j^a^seef^nf*^ requ -ifed-te- can provide the 

involved Node Bs with the IP addresses and UDP ports (in an IP UTRAN) or 
ATM addresses and SUGR parameters (in an ATM UTRAN) that they need to 
establish the inter-Node B transport bearers. If a transport network control 
plane protocol is used, the Node Bs handle can this transport network control 
plane signaling between themselves and intermediate routers or AAL2 switches 
for inter-Node B transport bearers.- However, there -is - no inter Node B RN L 
signaling. 

To direct a transport bearer between a DHO node or a leaf Node B (in the 
DHO node tree} and a hierarchically higher DHO node or the RNC in an IP 
UTRAN without a- using the transport layer control plane protocol, the RNC 
conveys to the DHO node or leaf Node B the destination IP address and UDP 
port to be used in the uplink direction of the transport bearer. That is, in 
essence, unless the hierarchically higher node is the RNC itself, the RNC 
replaces an IP address and a UDP port of the RNC {that would have been 
included in the message if distributed macro diversity had not been used) by 
an IP address and a UDP port of the hierarchically higher DHO node. The 
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receiving node returns the destination IP address and UDP port to be used in 
the downlink direction of the transport bearer. 

Please amend the paragraphs beginning at page 41, lines 1-12, as 
follows: 

To convey all these instructions to the involved Node Bs the RNC uses 
can use anyone or more of existing unchanged NBAP messages (and RNSAP 
messages), existing modified NBAP messages (and RNSAP messages) and even 
new NBAP messages (and RNSAP messages). 

One non-limiting aspect of the DHO related signaling is associated with 
the inter-RNS case. In the inter-RNS case the D-RNC more or less relays the 
information between the S-RNC and the Node Bs, using RNSAP towards the S- 
RNC and NBAP towards the Node Bs. It is however not a strict relay, since the 
D-RNC converts between two protocols. 

Since the DHO related information in an RNSAP message sent from the 
S-RNC to a D-RNC may be intended for any of the Node Bs in the RNS of the D- 
RNC, there must should, be a way for the S-RNC to indicate the intended 
recipient of the DHO related information. The preferred way to do this is to 
include a transport layer address (i.e. an IP address or an ATM address) of the 
intended recipient node together with the DHO related information that is 
included in an RNSAP message. This transport layer address should be the 
same address as the one that is used to represent the node in the topology 
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information, because this address is the only address of the node that the S~ 
RNC is guaranteed to know. However, if the intended recipient node is the D- 
RNC, the included transport layer address may be any address of the D-RNC 
that the S-RNC knows, e.g. the one that is used in the topology information or 
the one that is used as the destination address for the transport bearer used 
for the concerned RNSAP message. Likewise a transport layer address may be 
associated with DHO related information in RNSAP messages sent in response 
from a D-RNC to a S-RNC. 

Please amend the paragraph beginning at page 42, line 8, as follows: 

In another non-limiting embodiment of the present invention the RNC 
realizes the DHO node tree (i.e. directs the transport bearers in accordance 
with the DHO node tree) using unmodified NBAP and RNSAP protocols. The 
regular message formats are used and no new parameters are introduced. 

Please amend the paragraph beginning at page 42, line 17, as follows: 

The embodiment without protocol modifications ear * onlv be-is more 

a ppropriately used in an IP UTRAN without an IP control plane protocol. The 
reasons for this will be apparent from the further description of the solution. 
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Please amend the paragraphs beginning at page 44, line 24 through 
page 45, line 18, as follows: 

As stated above the RNC eannot - may not explicitly instruct a DHO node 
of what destination IP address and UDP port to use for a transport bearer 
towards a hierarchically lower node. Actually, the RNC cannot ma y not even 
explicitly inform a Node B that it has been selected as a DHO node and when 
the DHO functionality should be initiated or terminated. Instead a DHO 
enabled Node B has to rely on implicit information in the data flows to trigger 
initiation and termination of the DHO functionality and to find out where to 
direct split data flows. 

A DHO enabled Node B checks the source address of all the IP packets it 
receives at the IP address and UDP port allocated to the transport bearer(s) of a 
certain DCH, If a packet with a source address other than that of the next 
hierarchically higher node (or one of its next hierarchically lower nodes if the 
Node B is already acting as a DHO node) is received, this packet has to 
originate from a hierarchically lower node. This indicates to the Node B that it 
has become a DHO node for a new macro diversity leg of the concerned DCH 
and the destination IP address and UDP port to use for the split downlink flow 
for the new macro diversity leg are the same as the source IP address and UDP 
port of the received packet. The Node B then initiates the required DHO 
functionality and starts to perform splitting and combining accordingly. This 
principle cannot b e is not used in an ATM UTRAN or an IP UTRAN with a 
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transport layer control plane protocol, because in these types of UTRAN a Node 
B cannot send data to a hierarchically higher node, until the hierarchically 
higher node has established the transport bearer towards the Node B. 

The Node B does not receive any explicit QoS instructions for the new 
transport bearer towards the hierarchically lower node, so if needed, the Node 
B has-te-d erive derives the required QoS information from the DCH 
characteristics (which is already known in the Node B} or eepy- copies the QoS 
class (e.g. DiffServe code points) used for the transport bearer of the same DCH 
towards the next hierarchically higher node. 

Please amend the paragraph beginning at page 49, line 1, as follows: 

Another possible variation of the trigger mechanisms for termination of 
DHO functionality is to use timers instead of frame counters, but this variation 
would probably perform worse not necessaril y improve performance , since the 
TTI may be different for different DCHs. (Adapting the timeout value for the 
timers to the TTI of each DCH would eliminate this problem, but then there 
would in practice be no difference between running a timer and counting TTIs.) 

Please amend the paragraphs beginning at page 49, line IS through 
page 50, line 11, as follows: 

Using implicit information in the data flow to trigger termination of DHO 
functionality (as described above) i - He - vitably ^ aean -s -implies that a DHO node 
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will maintain DHO functionality for a DCH macro diversity leg for a period of 
time after the point in time when-after the hierarchically lower node stepped 
stops sending uplink frames on the concerned transport bearer. Consequently 
the DHO node (denoted A to simplify this description) will keep sending split 
downlink frames to an IP address and UDP port that are no longer allocated to 
this DCH transport bearer in the hierarchically lower node (denoted B). 

If the hierarchically lower node (B) has reallocated this IP address and 
UDP port to another DCH transport bearer {towards another hierarchically 
higher node C {note that nede-B- node A and node C may be the same node but 
for different DCHs)), this situation will cause the DHO functionality to 
malfunction in the hierarchically lower node (B). The packets that the 
hierarchically lower node (B) receives from the erroneously splitting DHO node 
(A) has a different source IP address and UDP port than the packets received 
from the correct hierarchically higher node (C) . Thus, if the hierarchically lower 
node (B) is DHO enabled, it will interpret the erroneously split packets from the 
old hierarchically higher node (A) as packets from a new hierarchically lower 
node and thus will initiate DHO functionality for what it believes to be a new 
macro diversity leg towards a hierarchically lower node (whereas it actually is 
an old macro diversity leg towards the old hierarchically higher node (A) which 
the old hierarchically higher node (A) has not stopped using yet) . If the 
hierarchically lower node (B) is not DHO enabled, the situation may cause 
unpredictable behaviour in the hierarchically lower node (B). 
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To avoid this problem a Node B Bms ^can make sure not to reallocate an 
IP address-UDP port pair for a time period no shorter than 

maxErroneousDHOperiod. After this time period a Node B may safely reallocate 
an IP address-UDP port pair, since any DHO functionality using this IP 
address-UDP port pair in a hierarchically higher DHO node isnsu^Feiy- should be 
terminated by then. This grace period for reallocation of IP address-UDP port 
pairs is a new functionality in a Node B. Hence, legacy (non-H-DHO aware) 
Node Bs in general cannot be used as leaf Node Bs in the solution with 
unmodified protocols. However, if a legacy {non-H-DHO aware) Node B filters 
incoming packets based on the source IP address (or source IP address and 
UDP port) such that packets with an unexpected source IP address (or 
unexpected source UDP port) are discarded, then this legacy Node B can be 
used as a leaf Node B in the solution with unmodified protocols. 

Please amend the paragraph beginning at page 52, line 6, as follows: 

To summarize, as illustrated in FIG. 17, the- a non-limiting method for 
providing DHO related instructions to a first DHO tree node, e.g. a Node B, that 
is or is planned to be a part of a DHO connection in a mobile 
telecommunication network, wherein the DHO functionality is distributed to 
one or a plurality of DHO nodes, such as a Radio Network Controller, RNC, and 
its connected Node Bs, in said network, comprises the steps of: 



-24- 



1473? IS 



AMENDMENT 

U.S. Serial No. 10/583,894 



Atty. Docket No.: 2380-1325 
Art Unit: 2617 



-1701. Include in a first signaling message one or more transport layer 
addresses and one or more transport bearer reference parameters in order to 
direct one or more data flows of the DHO connection. 

1702. Send said first signaling message to the first DHO tree node. 

Please amend the paragraphs beginning at page 52, line 27 through 
page 53, line 4, as follows: 

Thus, the -a non-limiting example RNC in-aee ordance w -kh-the-preseftt 



transport layer addresses and one or more transport bearer reference 
parameters in order to direct one or more data flows of the DHO connection 
and means for sending said signaling message to a DHO tree node. 



received from a hierarchically lower DHO tree node to trigger the initiation of 
DHO functionality for a macro diversity leg towards the hierarchically lower 
DHO tree node, wherein said DHO functionality comprises splitting and 
combining of data flows. 



-comprises means for including in a signaling message one or more 



Moreover, the- a non-limiting; example DHO node h 





-comprises means for using implicit information in data 
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